Repository navigation
Conversation
The role of a computer in a robot is a set of k3s node labels, and k3s applies node-label/node-taint only when a node registers, so it has to be chosen at bootstrap. - New flags: --robot, --role, --node-name, --label, --taint (server script), --agent-role/--agent-node-name/--agent-label/--agent-taint (agent script), --server (K3S_URL=https://<host>:6443 in the agent script, env still wins; also a TLS SAN of the server) and --tls-san. One run still produces server and agent scripts with one token. Values are validated (DNS labels, label and taint syntax); the kubernetes.io/ and k8s.io/ prefixes are refused. - New scripts/tn-k3s-node.sh, embedded only when a node flag is given: writes node-name to config.yaml when absent, and node-label+/node-taint+ to the drop-in config.yaml.d/98-teknoir-node.yaml (atomic, rewritten only when it differs, never touches keys the owner set). On a node that has registered already it warns and prints the kubectl label/taint commands. - Without the new flags the scripts are byte-identical (existing goldens). - Tests: validation, rendering, new roles goldens for server and agent, shell tests that run the config writer twice against a temp dir. - docs/commands/bootstrap.md: "Robots with several computers". Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
One conflict, in cmd/bootstrap.go: main added templates.ValidateTemplateData(data) right before the generate closure; nextgen turned that spot into nodes.apply(data) (server and agent get their own TemplateData) and a generate closure that takes the data. Resolution: validate the base data first (as on main, same error text), then apply the node options, then generate with the per-script data. The node fields are validated again in Render. The rest merged cleanly and was checked: - The scripts generated without the node flags are byte-identical to main (the server, agent and docker_server goldens are main's). - Main keeps the k3s token of a k3s that has started (keep-k3s-token block, which rewrites only "--token <generated>" in INSTALL_K3S_EXEC). The nextgen --server / --tls-san SANs are part of the same INSTALL_K3S_EXEC and survive it; new test TestReRunKeepsTheExistingK3sTokenWithNodeFlags covers it. The node drop-in (tn-k3s-node.sh) does not depend on the token. - Regenerated only the role goldens (server/agent .roles.golden.sh); against the plain goldens they differ only by the node block, the SANs and the node-name line. - docs/commands/bootstrap.md: states how the token behaves on re-runs with several computers (the agent script of a re-run carries a token the server no longer uses; pass K3S_TOKEN from server/token). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Node roles are k3s node labels, and k3s applies
node-label/node-taintonly when a computer registers, so the role is chosen at bootstrap (Anders: "the node role has to be chosen at bootstrap, right? So there might be changes to tnctl to do first").What
tnctl bootstrap:--robot,--role,--node-name, repeatable--labeland--taintfor the server script;--agent-role,--agent-node-name,--agent-label,--agent-taintfor the agent script from the same run (one run = one shared k3s token);--server <host>(bakesK3S_URLinto the agent script and adds the host to the server's--tls-san); repeatable--tls-san.teknoir.org/node-role,teknoir.org/robotand extras go to a drop-in/etc/rancher/k3s/config.yaml.d/98-teknoir-node.yaml(node-label+/node-taint+, never overwriting the owner's lists);node-namegoes into config.yaml only if absent. An already-registered node gets a warning with the kubectl command to apply the labels.kubernetes.io/andk8s.io/keys refused (NodeRestriction).Checks
🤖 Generated with Claude Code